Многие пользователи, которые начинают пользоваться средствами виртуализации от VMware, рано или поздно задаются вопросом - как создать копию виртуальной машины (клонировать её) в бесплатной версии VMware ESXi. Если у вас есть коммерческое издание VMware vSphere и сервер управления vCenter, то клонировать ВМ можно просто из контекстного меню машины:
Однако все несколько сложнее, если у вас бесплатная версия VMware ESXi Free (он же vSphere Hypervisor). Тут можно пойти вот какими путями:
Это средство позволяет вам создать виртуальную машину на целевом хосте (а именно на нашем бесплатном ESXi), установив сам Converter внутрь машины, и создать ее клон как физической системы. При этом в процессе клонирования ("миграции") сохраняется обе системы, а различные настройки, такие как размеры виртуального диска, имя системы и прочее, можно кастомизировать.
2. Использовать софт для резервного копирования и восстановления.
Сначала создаем резервную копию машины, а потом восстанавливаем ее параллельно с уже существующей ВМ.
3. Можно просто скопировать виртуальную машину и ее диск.
Первый вариант данного способа прост - копируете папку с ВМ (для доступа к файловой системе ESXi можно использовать WinSCP или FastSCP). Далее добавьте ВМ в окружение ESXi файл *.vmx через контекстное меню и пункт "Add to inventory":
Второй вариант - это использование утилиты vmkfstools. Она позволяет клонировать диски виртуальных машин, задавая различные параметры целевого диска. Например, вот эта команда создает клон виртуального диска, но целевой диск будет в thin-формате (то есть растущим по мере наполнения данными):
С помощью этой утилиты можно много чего делать, более подробно о ней написано в KB 1028042. Далее создаем новую ВМ и подцепляем к ней полученный виртуальный диск. Не забудьте поменять имя машины и сетевую идентификацию!
Есть еще способ сделать клон ВМ с помощью VMware vSphere Management Assistant (vMA) и vSphere CLI (vCLI) как написано в KB 1027872, но он требует развертывания vMA и не стоит заморочек ради клонирования одной ВМ. Но для регулярного клонирования машин - обязательно изучите эту KB.
Как вы знаете, у компании VMware был такой продукт как vCenter Server Heartbeat, который защищал управляющий сервер vCenter от сбоя различных его компонентов и на различных уровнях. Некоторое время этот продукт был снят с производства, и теперь защиту vCenter от сбоев рекомендуется обеспечивать стандартными средствами платформы VMware vSphere.
Надо сказать, что обеспечение надежности сервера vCenter, работающего в виртуальной машине (а сейчас уже мало кто ставит его в физической), начинается с обеспечения доступности и дублирования компонентов, которые находятся "под ним", а именно: хост-сервер ESXi, источники питания, хранилища, сетевые подключения и т.п.
Ну а, собственно, для правильной конфигурации самой платформы vSphere и сервера vCenter, компания VMware выпустила полезный документ "VMware vCenter Server 5.5 Availability Guide".
Итак, начнем с того, что VMware предлагает разделить сервисы vCenter на две большие части:
Compute Node - это сам vCenter и все сервисы к нему относящиеся (SSO, Web Client, Inventory service)
Data Node - это узел, где хранятся данные vCenter, попросту говоря, это СУБД и сама база данных.
Понятно, что оба этих компонента могут быть как на одном сервере (для небольшой инфраструктуры), так и в разных машинах, когда требуется производительная база данных (например, в Enterprise-окружениях).
Если у вас большая виртуальная инфраструктура, где есть множество управляющих компонентов, то вы можете выделить отдельный кластер из трех и более хостов чисто под эти нужды.
Но чаще всего у вас есть просто одна или максимум две виртуальные машины - одна под vCenter, вторая - под его базу данных.
Доступность Compute Node
Это раздел включает в себя доступность следующих комопнентов:
vCenter Single Sign-On services
vCenter Inventory Service
vCenter Server
vCenter Server management Web service
vSphere Web Client
Здесь рекомендуется настроить защиту средствами технологии VMware HA и придерживаться следующих рекомендаций:
Создавайте (по-возможности) отдельный кластер для управляющих сервисов - в случае отказа любого из компонентов сервисы будут перезапущены с помощью HA автоматически.
Включите не только VMware HA, но и технологию virtual machine monitoring, которая отключена по умолчанию. Это позволит перезапустить сервер с vCenter при зависании гостевой ОС.
Включите и настройте admission control в кластере HA/DRS, где работает vCenter. Это позволит гарантированно перезапустить vCenter на одном из хостов в случае сбоя.
Установите restart priority в настройках HA для машины с vCenter Server в значение "High". Он будет первым запускаться.
Если ваш vCenter находится в Windows-машине, то можно настроить автоматический рестарт машины при невозможности после многократных попыток запустить службу vCenter Service.
Выглядеть это может примерно вот так (только помните, что в случае такй настройки, виртуальная машина может впасть в цикл бесконечных перезагрузок).
Если у вас компоненты vCenter на разных машинах, не забудьте установить правило affinity rule, чтобы машины оказались на одном хосте при миграции и восстановлении, в целях сохранения максимальной производительности управляющего сервиса.
Также для гарантии можно выделить управляющим компонентам гарантированную физическую память (Memory Reservation) в настройках виртуальной машины.
Доступность Data Node
Тут VMware приводит следующие рекомендации:
Также, как и в случае с Compute Node, рекомендуется использовать для управляющих сервисов и базы данных отдельный кластер.
Если вы используете решение для кластеризации vCenter, необходимо убедиться, что настройка ForceAffinePoweron в параметрах vSphere DRS установлена в значение 1, чтобы включать сервер БД, несмотря на правила DRS.
Так же, как и в случае с Compute Node, используйте технику virtual machine monitoring для перезапуска зависшей гостевой ОС.
То же самое и про admission control - используйте его для гарантированного восстановления ВМ с сервером БД.
Аналогично Compute Node, установите restart priority в настройках HA для машины с базой данных в значение "High". Он будет первым запускаться.
Для защиты vCenter Server SQL Server database можно использовать Microsoft Failover Clustering, который официально поддерживается со стороны VMware. Табличка совместимости СУБД и версий vCenter приведена ниже.
Для тех из вас, кто по каким-либо причинам еще не обновился на vSphere 5.5, полезная новость - вышло обновление VMware vSphere 5.1 Update 3 (ESXi и vCenter), которое уже доступно для загрузки. Новых возможностей не появилось, зато была добавлена поддержка новых гостевых ОС и исправлены некоторые значимые баги.
Итак, что нового в ESXi и vCenter 5.1 U3:
Поддержка новых БД vCenter Server - теперь можно использовать
Oracle 12c и
Microsoft SQL Server 2014
Поддержка новых браузеров для Web Client 5.1 Update 3. Теперь поддерживаются:
Internet Explorer 8 / 9 / 10/ 11
Firefox 31 / 32 / 33
Google Chrome 36 / 37
Поддержка новых гостевых ОС. Полный список поддерживаемых ОС можно посмотреть тут.
Тем из вас, у кого скопилось несколько сотен лишних долларов в это непростое время, компания VMware предлагает приобрести подписку на новый обучающий сервис - VMware Learning Zone. Данный сервис позволяет получить доступ к платным обучающим видеороликам на базе годовой подписки в режиме 24/7:
Платная подписка VMware Learning Zone позволяет:
Смотреть обучающие видеоролики и туториалы по последним продуктам и технологиям VMware.
Искать в библиотеке платных видеороликов нужные материалы.
Получать информацию о решении проблем, развертывании решений и их настройке в рамках курсов уровня "deep dive".
Получать доступ к курсам с мобильных устройств, а также принимать участие в обсуждениях сообществ, помогающих решать проблемы, возникающие в процессе эксплуатации решений VMware.
В рамках подписки на данный момент доступны курсы по следующим темам:
Deep Dive: VMware Directory Services (vmdir) Database
Disaster Recovery
ESXi: Network Troubleshooting at the ESXi Command Line
VMware Cloud Automation Center 6.0
Configuring vCenter Single Sign-On
vCenter Site Recovery Manager
vCenter
vCloud Air: Connecting your Data Center To vCloud Air - Tips and Techniques
vCloud Suite: Up to Speed - vCloud Director Rest API for Beginners
Virtual Machine Disk (VMDK) Snapshots
Virtual SAN Troubleshooting
VMRC and Media Upload Troubleshooting
VMware Horizon 6
Virtual SAN 5.5
vSphere Managed Object Browser
Ну и главное - цена. Если считать по курсу на 31 декабря этого года, то получается что-то около 80 тысяч рублей за годовую подписку:
Купить годовой доступ к VMware Learning Zone можно по этой ссылке.
Как знают многие администраторы VMware vSphere, в инфраструктуре хранилищ иногда возникает проблема выравнивания виртуальных дисков машин (последний раз мы писали об этом тут). Некорректное выравнивание блоков может возникать на двух уровнях - гостевой ОС по отношению к VMFS и VMFS по отношению к блокам дискового массива:
В целом-то, эта проблема не очень актуальна в последнее время, учитывая что в последних версиях VMware vSphere и ОС Windows с этим вполне разобрались. Однако для тех, у кого инфраструктура очень древняя (особенно с ВМ на базе Windows 2003 и 2008), пережила несколько апгрейдов и миграций - выравнивание блоков проверить было бы нелишним.
Именно для этого и была выпущена бесплатная утилита VM Check Alignment. Утилита старенькая, но вполне себе работает для Windows 2003/2008 и Windows Vista/7:
В параметре Starting Offset мы видим, что виртуальный диск выровнен корректно, и никаких изменений не требуется. Для некорректно выровненных дисков, кстати, производительность хранилищ может падать на величину до 10%.
О том, как нужно выравнивать блоки виртуальных дисков написано тут и тут.
Компания VMware выпустила еще один интересный документ, описывающий референсную архитектуру программно-определяемого датацентра (SDDC) - "Creating a VMware Software-Defined Data Center".
В данном документе на 29 страницах приводится пример создания корпоративной инфраструктуры на базе следующих продуктов:
Описание программных компонентов для построения SDDC-инфраструктуры
Обзор референсной архитектуры
Информация об оборудовании и аппаратных компонентах
Детальная информация о компонентах Software-Defined Data Center
Высокоуровневая конфигурация инфраструктуры SDDC
В рассматриваемой архитектуре есть три основных модуля:
Management Cluster - основной кластер управления и мониторинга, в котором работают такие средства как vCenter, Log Insight и прочие. Состоит минимум из трех хост-серверов ESXi.
Edge Cluster - отдельный кластер для управления сетевым взаимодействием. Он упрощает конфигурацию физической сети передачи данных путем создания абстракции физического сетевого стека в ИТ-инфраструктуре. Также содержит минимально 3 хоста.
Payload Cluster - "рабочая лошадка" виртуальной инфраструктуры, кластер, где крутятся рабочие нагрузки. Может масштабироваться "подами" (pods) по мере роста потребностей предприятия.
В целом документ весьма интересный, так как в комплексе затрагивает управляющие компоненты виртуальной инфраструктуры и показывает работу средств управления большой виртуальной средой, а также то, каким образом эти средства решают возникающие в такой инфраструктуре проблемы.
Ниже мы приведем еще один аргумент в пользу того, чтобы не создавать снапшоты виртуальных машин на постоянной основе (во временном их использовании нет ничего плохого).
Итак, в одной из статей мы писали про расширенную настройку VMFS Heap Size (размер кучи), которая косвенно определяет максимально доступный объем хранилищ на хосте.
Также мы писали о том, что параметр VMFS3.MaxHeapSizeMB еще в VMware vSphere 5.1 был увеличен до 640 МБ.
Однако есть и куча для механизма "Copy-on-Write" (COW), которая определяется расширенной настройкой COW.COWMaxHeapSizeMB - она ограничивает число одновременно запущенных на хосте виртуальных машин. Механизм COW работает на хосте, когда у машины есть снапшоты (дельта-диски).
По умолчанию это значение равно 192 МБ, но может быть увеличено до 256 МБ:
Также этот параметр можно узнать из командной строки:
~ # esxcfg-advcfg -g /COW/COWMaxHeapSizeMB
Value of COWMaxHeapSizeMB is 192
И установить его в максимальное значение:
~ # esxcfg-advcfg -s 256 /COW/COWMaxHeapSizeMB
Value of COWMaxHeapSizeMB is 256MB
Давайте посмотрим, как расходуется пространство этой кучи на хосте, в зависимости от параметров виртуальных машин на нем. Вот тут есть такая интересная формула:
X - это максимальное число запущенных виртуальных машин на хосте,
COW_HEAP_SIZE - размер кучи в байтах,
B - размер виртуального диска в байтах,
2 * 1048576 - это GDE Coverage (хз, что такое),
4 - это число байт на Root Entry,
S - число снапшотов каждого из виртуальных дисков,
Y - число дисков у машин.
Возьмем для примера машину с 5 дисками размером в 80 ГБ по 6 снапшотов у каждого при максимальном размере кучи в 256 МБ. Получим, что таких машин может быть запущено на хосте:
Это примерно около 40 машин (всего лишь) - при максимально доступном размере кучи на VMware ESXi. Понятно дело, что мало где можно найти машины с 5 дисками, у каждого из которых по 6 снапшотов, но я видел подобные конфигурации пару раз.
Нетрудно понять, как в этой формуле влияют снапшоты на максимальное число запущенных виртуальных машин. Поэтому повторим еще раз: постоянные снапшоты - зло.
Как многие из вас знают, у компании VMware есть бесплатный продукт VMware vSphere Hypervisor, который в народе называется VMware ESXi Free. Многие начинающие администраторы, услышав, что ESXi бесплатен, устанавливают его, но забывают накатить лицензию, которую надо скачивать с портала My VMware. Без этого бесплатный VMware ESXi будет работать в режиме пробной версии 60 дней...
Многие администраторы устанавливают VMware Tools с помощью vSphere Client, который предоставляет идущую в дистрибутиве версию этого пакета. Однако не все знают, что VMware Tools можно скачать по прямой ссылке из репозитория VMware, затем положить exe-файл на файловый сервер (если у вас гостевая ОС Windows) и запускать на всех виртуальных машинах.
Последняя версия тулзов всегда находится по этой ссылке:
Но эти пакеты доступны только для следующих версий гостевых ОС:
Community ENTerprise Operating System (CentOS) - версии с 4.0 по 6.x
Red Hat Enterprise Linux версии с 3.0 по 6.x
SUSE Linux Enterprise Server версии 9 по 11
SUSE Linux Enterprise Desktop версии 10 по 11
Ubuntu Linux версии с 8.04 по 12.04
Надо отметить, что доступные в репозитории пакеты содержат компоненты VMware Tools, начиная еще с версий ESX 3.5. Но с версии vSphere 4.1 все они стали обратно совместимы - вы можете скачать последнее обновление VMware Tools и накатить его на любую версию vSphere 4.x или 5.x.
Кроме того, если в списке остутствуют необходимые ОС Linux, то можно воспользоваться пакетом Open VM Tools, которые являются открытой версией VMware Tools и рекомендованы к распространению вендорами платформ. Например, вот тут указано, как нужно ставить Open VM Tools в гостевых ОС RHEL 7.
Как установить IP-параметры HP iLO через консоль сервера VMware ESXi.
При развертывании инфраструктуры VMware vSphere на базе серверов HP всегда требуется задать параметры IP-идентификации для интерфейса удаленной консоли iLO. Обычно это делается в настройках сервера, но удобнее сделать это из консоли ESXi, если вы используете кастомизированную сборку ESXi под HP (а ее надо использовать, так как некоторые девайсы могут просто не работать, поскольку в стандартной сборке под них нет драйверов).
Для начала откроем на хосте ESXi доступ по SSH в разделе Security Profile, стартовав соответствующий сервис:
Заходим на хост по SSH и переходим в папку с утилитами HP:
cd /opt/hp/tools
Копируем настройки HP iLO в файл XML:
./hponcfg -w ilo.xml
Далее этот файл нам нужно отредактировать, для этого можно использовать WinSCP или Veeam FastSCP.
Копируем iLO.xml к себе локально:
Открываем его в текстовом редакторе и правим секции, помеченные красным:
<!-- HPONCFG VERSION = "4.0-13.0" -->
<!-- Generated 11/11/2014 23:37:47 -->
<RIBCL VERSION="2.1">
<LOGIN USER_LOGIN="Administrator" PASSWORD="password">
<DIR_INFO MODE="write">
<MOD_DIR_CONFIG>
<DIR_AUTHENTICATION_ENABLED VALUE = "N"/>
<DIR_LOCAL_USER_ACCT VALUE = "Y"/>
<DIR_SERVER_ADDRESS VALUE = ""/>
<DIR_SERVER_PORT VALUE = "636"/>
<DIR_OBJECT_DN VALUE = ""/>
<DIR_OBJECT_PASSWORD VALUE = ""/>
<DIR_USER_CONTEXT_1 VALUE = ""/>
<DIR_USER_CONTEXT_2 VALUE = ""/>
<DIR_USER_CONTEXT_3 VALUE = ""/>
</MOD_DIR_CONFIG>
</DIR_INFO>
<RIB_INFO MODE="write">
<MOD_NETWORK_SETTINGS>
<SPEED_AUTOSELECT VALUE = "Y"/>
<NIC_SPEED VALUE = "100"/>
<FULL_DUPLEX VALUE = "N"/> <IP_ADDRESS VALUE = "192.168.16.33"/>
<SUBNET_MASK VALUE = "255.255.255.0"/>
<GATEWAY_IP_ADDRESS VALUE = "192.168.16.254"/>
<DNS_NAME VALUE = "ESX01-iLO"/>
<PRIM_DNS_SERVER value = "192.168.16.1"/>
<DHCP_ENABLE VALUE = "N"/>
<DOMAIN_NAME VALUE = "educ.local"/>
<DHCP_GATEWAY VALUE = "Y"/>
<DHCP_DNS_SERVER VALUE = "Y"/>
<DHCP_STATIC_ROUTE VALUE = "Y"/>
<DHCP_WINS_SERVER VALUE = "Y"/>
<REG_WINS_SERVER VALUE = "Y"/>
<PRIM_WINS_SERVER value = "0.0.0.0"/>
<STATIC_ROUTE_1 DEST = "0.0.0.0" GATEWAY = "0.0.0.0"/>
<STATIC_ROUTE_2 DEST = "0.0.0.0" GATEWAY = "0.0.0.0"/>
<STATIC_ROUTE_3 DEST = "0.0.0.0" GATEWAY = "0.0.0.0"/>
</MOD_NETWORK_SETTINGS>
</RIB_INFO>
<USER_INFO MODE="write">
</USER_INFO>
</LOGIN>
</RIBCL>
Копируем измененный файл обратно на хост ESXi (предыдущий сохраните - просто переименуйте) и выполняем команду заливки конфигурации:
./hponcfg -f ILO.xml
Дождитесь успешного выполнения команды - и можно коннектиться к iLO через веб-браузер по новому адресу. Этот способ удобен тем, что можно не перезагружать сервер.
Многие пользователи VMware Virtual SAN (VSAN), когда проводят тест бэкапа одной виртуальной машины, замечают, что время резервного копирования этой ВМ существенно больше, чем таковое для машины, размещенной на дисковом массиве.
Дункан в своем блоге подробно разбирает эту проблему. Тут дело вот в чем - когда вы используете дисковый массив, то виртуальная машина "размазывается" по дискам RAID-группы, что позволяет читать одновременно с нескольких дисков. Это дает хорошую производительность операции резервного копирования для одной машины.
Кластер же VSAN работает немного по-другому. Это объектное хранилище, в котором виртуальный диск ВМ хранится на одном хосте и его реплика существует на втором. Кроме этого, есть кэш на SSD-диске (но его еще нужно "прогреть"). То есть выглядит все это следующим образом:
Соответственно, при бэкапе одной виртуальной машины данные читаются только с двух HDD-дисков, а не с нескольких как в традиционной архитектуре дисковых массивов, при этом сам кластер VSAN может состоять из нескольких хостов (до 32 узлов). То есть, это архитектурное ограничение.
Однако если мы будем делать одновременный бэкап нескольких виртуальных машин с хранилища Virtual SAN время этой операции уже будет сравнимо с дисковым массивом, поскольку будет задействовано сразу несколько дисков на каждом из хостов, плюс хорошо прогреется кэш. Поэтому проведение такого теста (ведь он ближе к реальным условиям) и было бы более показательным при сравнении Virtual SAN и традиционных хранилищ.
То же самое относится и к VDI-инфраструктуре на базе VSAN - многие пользователи отмечают, что первая фаза операции Recompose (когда создается реплика - полный клон ВМ) отрабатывает весьма медленно. Однако если вы делаете много таких операций - кэш прогревается, и одновременное создание нескольких клонов начинает работать заметно быстрее в расчете на одну машину.
Многие пользователи в целях безопасности хотят отключить использование USB-портов на хостах VMware ESXi - а то кто-нибудь зайдет в серверную комнату и утащит данные на диске.
К сожалению, на текущих версиях платформы VMware vSphere сделать этого нельзя. Можно, конечно, отключить USB Arbitrator service следующей командой (как написано вот тут):
/etc/init.d/usbarbitrator stop
Но это лишь отключит проброс USB-устройств в виртуальные машины, при этом само устройство (например, /dev/usb0101) отключено не будет. Поэтому, тут остается два решения:
Отключить USB-устройства в BIOS - но это поддерживают не все производители железа.
Мониторить использование локальных USB-устройств и слать алерты менеджеру по ИБ.
Второй вариант можно реализовать с помощью продукта VMware vRealize Log Insight, который позволяет мониторить логи хостов ESXi и слать по ним алерты при их появлении и повторении. Вот, например, в выводе этого лога мы видим, что кто-то подключал USB-девайс к хосту:
Сопоставив время этих событий и время посещения конкретными людьми датацентра, мы поймем, кто пытался или сделал что-то нехорошее. Решение, конечно, не ахти, но какое уж есть.
Бывают такие ситуации, когда у вас в руках только мобильный телефон, с которого возникает необходимость перезагрузить виртуальную машину на хосте VMware ESXi. Например, у вас в инфраструктуре что-то случилось, но вы имеете доступ к ней через VPN со своего айфона.
Если у вас есть доступ по SSH, то проблему решить весьма просто, как это описано вот тут (а также в KB 1014165). Скачиваем бесплатное приложение Server Auditor по этой ссылке (если у вас андроид - то по этой).
Далее заходим на свой хост ESXi по SSH и выполняем команду:
esxcli vm process list
Будет выведен список всех процессов виртуальных машин, где нам нужно найти World ID нужной машины. Записываем или запоминаем его.
Далее убиваем виртуальную машину командой (вместо параметра force можно использовать hard и soft для выключения ВМ):
esxcli vm process kill -t force -w WorldID
Выглядит это примерно вот так:
Далее снова выполняем команду esxcli vm process list, чтобы убедиться, что виртуальная машина теперь выключена.
Теперь запоминаем VMID нашей виртуальной машины, который можно получить с помощью команды:
vim-cmd vmsvc/getallvms
Если помните часть имени ВМ, можно искать с помощью grep:
vim-cmd vmsvc/getallvms |grep <текст в имени ВМ>
Найдя VMID, проверяем дополнительно, что она выключена:
vim-cmd vmsvc/power.getstate <vmid>
Теперь включаем виртуальную машину:
vim-cmd vmsvc/power.on <vmid>
Вот и все, потом обязательно нужно проверить, что машина включилась, естественно - сначала в списке процессов, а потом пингом.
Некоторое время назад мы писали о технологии VMware vFlash (она же Virtual Flash), которая позволяет использовать высокопроизводительные накопители SSD (вот тут - о производительности) для решения двух важных задач:
Предоставление виртуальным машинам дополнительного места, в которое будут свопиться страницы памяти в случае недостатка ресурсов на хосте (это намного более производительно, чем свопить на обычный HDD-диск). Эта техника называется Virtual Flash Host Swap и пришла на смену механизму Swap to SSD.
Прозрачное встраивание в поток ввода-вывода на хосте между виртуальными машинами и хранилищами, что позволяет существенно ускорить операции чтения данных виртуальных дисков. Называется это VMware Flash Read Cache (vFRC).
Ниже мы вкратце расскажем о настройке этих двух механизмов через VMware vSphere Web Client (в обычном C#-клиенте этого, к сожалению, нет). Если что, более подробно о технике vFRC можно почитать по этой ссылке.
Итак, в vSphere Web Client переходим на вкладку "Manage" для нужного хоста, далее в разделе "Settings" выбираем пункт "Virtual Flash Resource Management". Это кэш, который мы добавляем для того, чтобы в случае нехватки места, его могли использовать виртуальные машины, чтобы не свопить данные на медленный магнитный диск, кроме того он же будет использоваться для целей vFRC.
Нажимаем Add Capacity:
Выбираем диски, которые мы будем использовать как Host Swap и нажимаем "Ок" (все данные на них будут стерты):
Всего под нужды Virtual Flash может быть выделено до 8 дисков суммарной емкостью до 32 ТБ. Видим, что ресурс добавлен как Virtual Flash Resource (его емкость отдельно учитывается для vFRC и Host Cache):
Настройка Virtual Flash Host Swap
Первым делом рекомендуется настроить именно этот кэш, а остаток уже распределять по виртуальным машинам для vFRC.
Выбираем пункт "Virtual Flash Host Swap Cache Configuration" в левом меню, а далее в правой части мы нажимаем кнопку "Edit":
Указываем необходимый объем, который планируется использовать, и нажимаем "Ок":
После того, как мы настроили нужное значение - в случае недостатка ресурсов на хосте виртуальные машины будут использовать высокоскоростные диски SDD для своих нужд внутри гостевой ОС (файлы подкачки прочее).
Настройка VMware Flash Read Cache (vFRC)
Напомним, что это кэш только на чтение данных, операции записи будут производиться на диск, минуя флэш-накопители. Соответственно, такой кэш улучшает производительность только операций чтения.
Сам кэш vFRC можно настроить на уровне отдельных виртуальных машин на хосте VMware ESXi, а также на уровне отдельных виртуальных дисков VMDK.
Чтобы выставить использование нужного объема vFRC для отдельной виртуальной машины, нужно выбрать пункт "Edit Settings" из контекстного меню ВМ и на вкладке "Virtual Hardware" в разделе "Virtual Flash Read Cache" установить нужное значение для соответствующего виртуального диска:
Если этого пункта у вас нет, то значит у вас версия виртуального "железа" (Virtual Machine Hardware) ниже, чем 10, и ее нужно обновить.
По ссылке "Advanced" можно настроить размер блока для кэша (значение Reservation, установленное тут, обновит значение на предыдущем скрине):
Ниже приведем ссылки на статьи VMware Knowledge Base (взято отсюда), где можно узнать о расположении и назначении файлов журнала (логов) для различных продуктов, включая компоненты решения VMware vSphere.
Четыре с половиной года назад мы писали про то, что у технологии Transparent Page Sharing (TPS), которая по-умолчанию используется в VMware vSphere, нет будущего. Напомним, что TPS - это механизм поиска и удаления дубликатов страниц памяти в целях экономии физического пространства RAM (вместо самой дублирующейся страницы хранится ссылка на нее).
Технолония потеряла актуальность, когда вовсю стали применяться большие страницы памяти (Large Memory Pages), для которых размер страницы равен 2 МБ, а значит вероятность появления двух полностью одинаковых страниц очень низка.
Более подробно о проблемах с TPS написано вот в этой статье на блогах VMware.
Если же вы хотите отключить этот механизм уже прямо сейчас, то нужно сделать следующее:
Залогиниться на ESX\ESXi или vCenter Server через vSphere Client.
Выбрать нужный хост и зайти на вкладку Configuration, затем перейти в Advanced Settings в секции Software.
Выбираем раздел Mem и в нем устанавливаем значение параметра Mem.ShareScanGHz в 0.
После патча и обновлений ESXi механизм TPS можно будет включить следующим образом (Advanced Settings в секции Software):
Параметр Mem.ShareForceSalting (включение TPS на уровне всего хоста ESXi). Если значение стоит 0 - то значит TPS по-прежнему работает на хосте, если 1 - механизм отключен.
Параметр sched.mem.pshare.salt (ставится на уровне ВМ) позволяет включать/отключать TPS для отдельных виртуальных машин (например, старые Windows или линуксы - для них можно было бы включить). Когда параметр ShareForceSalting установлен в значение 1, то для нуждающихся в TPS машин в их Advanced Configuration нужно установить одинаковые значения "соли". Без этого TPS не работает - соответственно, он отключен.
Часто пользователям требуется информация о том, какому номеру билда соответствует версия продукта от VMware (такое бывает нужно, например, для VMware vSphere / ESXi, vCenter, vCenter Server Appliance). К тому же, иногда бывает полезно узнать, когда вышла та или иная версия продукта.
Поэтому мы взяли из этого поста информацию о продуках, датах релиза и номерах версий, чтобы можно было всегда обращаться к этому посту у нас.
Новая архитектура сервисов управления VMware vCenter в VMware vSphere 6.
Некоторое время назад мы писали о новых возможностях платформы виртуализации VMware vSphere 6, о которых было подробно рассказано на прошедшей конференции VMworld 2014. Одним из нововведений новой версии станет новая архитектура сервисов управления VMware vCenter.
Надо начать с того, что "толстый" десктопный клиент vSphere Client в vSphere 6 по-прежнему останется доступен для управления виртуальными машинами через vCenter. Причины просты - компании VMware так и не удается довести до ума Web Client - он все еще притормаживает и не настолько быстро обновляет статус объектов, как это делает обычный vSphere Client. Однако все новые возможности будут появляться только в vSphere Web Client.
С точки зрения самого vCenter появляется новый сервис Platform Services Controller (PSC), который заменяет существующие сервисы Single Sign-On (напомним, что они уже были переписаны в версии SSO 5.5). Если ранее SSO был частью vSphere и обновлялся только вместе с платформой, то теперь PSC может быть обновлен отдельно (например, если появились новые источники аутентификации или были исправлены ошибки), что очень удобно.
На картинке ниже Infrastructure Controller (это так сейчас в бете называется Platform Services Controller) может быть выделен для каждого сервиса vCenter, но также и несколько сервисов vCenter могут использовать один PSC.
В обоих случаях сохраняются функции синхронизации данных между контроллерами и механика их отказоустойчивости.
Помимо стандартных функций аутентификации SSO, компонент PSC возьмет на себя управление лицензиями, а также хранение сертификатов.
Когда у вас до 8 серверов vCenter в рамках одной географической площадки, то можно использовать один PSC (который устанавливается на том же хосте, где и один из серверов vCenter). Ну а если у вас несколько датацентров, то для каждого разумнее использовать свой PSC, к которому подключаются не только сервисы vCenter, но и другие компоненты виртуальной инфраструктуры, например, продукт для управления облачной инфраструктурой VMware vCAC или средства автоматизации vRealize Orchestrator (бывший vCenter Orchestrator):
Шестую версию vCenter уже настоятельно рекомендуют устанавливать в виртуальной машине, так как только тогда можно будет воспользоваться преимуществами технологий отказоустойчивости и непрерывной доступности VMware HA и VMware Fault Tolerance. Ранее был продукт и для физических серверов - vCenter Heartbeat, но его сняли с производства.
Настало время объединить все сервисы управления виртуальной средой (vCenter, серверы vCAC, vCenter Log Insight, vCenter Orchestrator, vCenter Operations Manager и т.п.) в виде блоков в виртуальных машинах:
Также весьма существенно будет доработан виртуальный модуль vCenter Server Appliance (vCSA). Теперь он будет поддерживать до 1 000 серверов ESXi под своим управлением, 10 000 включенных виртуальных машин, 64 хоста ESXi на кластер HA/DRS, 6 000 ВМ в кластере, а также 10 серверов vCenter в режиме Linked Mode.
Как многие из вас знают, ранее режим Linked Mode не поддерживался со стороны vCSA, так как для этого режима использовалась модель Active Directory Application Mode (ADAM), не поддерживаемая в Linux. Теперь для Linked Mode используется собственная аутентификация, поэтому объединение нескольких машин vCSA в единую мета-сущность теперь вполне возможно.
Как Windows-версия, так и vCSA будут использовать встроенную БД vPostgres, а в качестве внешних БД стандартно будут поддерживаться Microsoft SQL Server и Oracle.
Ну и, помимо всего прочего, сейчас ходят слухи о выпуске вместе с VMware vSphere 6 утилиты для миграции с Windows-версии vCenter на vCSA. Эта штука для многих пользователей будет очень кстати.
ИТ-ГРАД запускает новую облачную площадку в дата-центре SDN. Перед переводом площадки в промышленную эксплуатацию мы должны убедиться в том, что все ее компоненты работают как задумывалось, а дублирование и обработка аппаратных сбоев происходит в штатном режиме. Для проверки работоспособности новой облачной площадки был разработан план тестирования, с которым вам и предлагаем ознакомиться.
Немного о наполнении новой площадки:
На первом этапе в новый ЦОД была установлена система хранения данных NetApp FAS8040 (мы как золотой партнер компании NetApp – остаемся верны вендору), система пока имеет 2 контроллера FAS8040, которые собраны в кластер через дублируемые 10Gbit/s коммутаторы (Cluster Interconnects) и позволяют наращивать кластер СХД до 24 контроллеров. Контроллеры СХД в свою очередь подключены к сети ядру сети по 10Gbit/s оптическим линкам сформированое двумя коммутаторами Cisco Nexus 5548UP с поддержкой L3.
Серверы гипервизоров VMware vSphere ESXi (Dell r620/r820) подключаются к сети по двум интерфейсам 10Gbit/s, используя конвергентную среду передачи данных (для работы с дисковым массивом и сетью передачи данных). Пул ESXi серверов образует кластер с поддержкой VMware vSphere High Availability (HA). Менеджмент интерфейсы серверов iDRAC и контроллеров СХД собираются на отдельном выделенном коммутаторе Cisco.
Когда базовая настройка инфраструктуры фактически была завершена настало время остановиться и оглядеться назад: ничего не забыли? все ли работает? надежно?
Задел на успех в лице опытных инженеров мы уже имеем, но чтобы «фундамент» оставался крепким, необходимо, конечно же, правильно провести испытания на стрессоустойчивость инфраструктуры. Успешное окончание тестов будет свидетельствовать о завершении первого этапа и сдачи приемо-сдаточных испытаний (ПСИ) новой облачной площадки.
Итак, озвучу «исходные данные» и «план тестирования». А внимательные читатели, которым не чужда судьба ИТ-ГРАДа, могут внести предложения/рекомендации/пожелания возможных моментов, которые мы могли не предусмотреть. С радостью их выслушаем.
«Исходные данные»:
FAS8040 dual controller под управлением Data ONTAP Release 8.2.1 Cluster-Mode
Коммутаторы ядра унифицированной сети Cisco Nexus 5548 – 2 шт.
Пограничный роутер Juniper MX80 (пока один, второй ещё не приехал).
Управляемый коммутатор Cisco 2960.
Серверы Dell PowerEdge R620/R810 with VMware vSphere ESXi 5.5.
Схема подключения выглядит следующим образом:
Нарочно не стал рисовать менеджмент свитч и Juniper MX80, т.к. связность интернет будем тестировать после резервирования канала, не хватает ещё одного Juniper MX80 (ждем к концу месяца).
Итак, условно наши «краш-тесты» можно поделить на 3 вида:
Тестирование дискового массива FAS8040;
Тестирование сетевой инфраструктуры;
Тестирование виртуальной инфраструктуры.
При этом тестирование сетевой инфраструктуры в нашем случае выполняется в укороченном варианте по причинам, которые я указывал выше.
Перед тестами планируется ещё раз сделать бэкапы конфигураций сетевого оборудования и массива, а также проанализировать результаты дискового массива с помощью Config Advisor.
Теперь давайте расскажу подробнее о плане тестирования.
I. Удаленное тестирование
Поочередное выключение контроллеров FAS8040.
Ожидаемый результат: автоматический takeover на рабочую ноду, все ресурсы VSM должны быть доступны на ESXi, доступ к датасторам не должен пропадать.
Поочередное отключение всех Cluster Link одной ноды.
Ожидаемый результат: автоматический takeover на рабочую ноду, либо перемещение/переключение VSM на доступные сетевые порты на второй ноде, все ресурсы VSM должны быть доступны на ESXi, доступ к датасторам не должен пропадать.
Отключение всех Inter Switch Link между свичами CN1610.
Ожидаемый результат: предполагаем, что кластерные ноды будут доступны друг для друга через cluster links одного из Cluster Interconnect (в связи с перекрестным соединением NetApp — Cluster Interconnect).
Перезагрузка одного из Nexus.
Ожидаемый результат: один из портов на нодах должен оставаться доступным, на IFGRP интерфейсах на каждой ноде должен оставаться доступен один из 10 GbE интерфейсов, все ресурсы VSM должны быть доступны на ESXi, доступ к датасторам не должен пропадать.
Поочередное гашение одного из vPC (vPC-1 или vPC-2) на Nexus.
Ожидаемый результат: перемещение/переключение VSM на доступные сетевые порты на второй ноде, все ресурсы VSM должны быть доступны на ESXi, доступ к датасторам не должен пропадать.
Поочередное отключение Inter Switch Link между коммутаторами Cisco Nexus 5548.
Ожидаемый результат: Port Channel активен на одном линке, нет потери связности между коммутаторами.
Поочередное жесткое отключение ESXi.
Ожидаемый результат: отработка HA, автоматический запуск ВМ на соседнем хосте.
Слежение за отработкой мониторинга.
Ожидаемый результат: получение нотификаций от оборудования и виртуальной инфраструктуры о появившихся проблемах.
II. Непосредственно на стороне оборудования
Отключение кабелей питания (все единицы оборудования).
Ожидаемый результат: оборудование работает на втором блоке питания, нет проблем с переключением между блоками.
Замечание: Менеджмент свитч Cisco не имеет резервирования питания.
Поочередное отключение сетевых линков от ESXi (Dell r620/r810).
Ожидаемый результат: ESXi доступен по второму линку.
На днях компания VMware выпустила очень полезный для администраторов виртуальных инфраструктур документ VMware Horizon 6 Reference Architecture на 53 страницах, в котором приведена типовая конфигурация VDI-среды на 2000 виртуальных ПК, расширяемая до 10 000 пользователей в случае необходимости.
В документе рассмотрена архитектура на базе серверной инфраструктуры Supermicro и хранилища EMC VNX 5500. На данной конфигурации удалось добиться следующих результатов:
Конфигурация программно-аппаратного комплекса:
Хосты ESXi с процессорами 2.1 ГГц Intel E5-2658 или 2.9 ГГц E5-2690
128 ГБ RAM на один хост ESXi
Хранилище для виртуальных ПК EMC VNX5500 на базе протокола NFS (20 ТБ)
Сетевое оборудование 10 Gigabit Ethernet (GbE)
Виртуальные машины Windows 7 с одним vCPU и 1GB vRAM (типовая "легкая" пользовательская нагрузка)
Виртуальные машины с ролью Microsoft Remote Desktop Session Host (RDSH) с четырьмя vCPU и 24 ГБ RAM
ПО VMware Horizon 6 на платформе VMware vSphere 5.5
А вот собственно и сама аппаратная конфигурация описанной в документе архитектуры:
В качестве составляющих программной среды используются все компоненты решения VMware Horizon 6 (View, Mirage 5.0 и Workspace Portal 2.0), работающие на платформе VMware vSphere 5.5.
Документ очень насыщен техническими деталями и рекомендуется к прочтению всем тем, кто планирует масштабное развертывание инфраструктуры виртуальных и физических ПК на базе семейства решений VMware Horizon 6.
Не так давно мы писали о новых возможностях лидирующей на рынке платформы виртуализации VMware vSphere 6, которая на данный момент доступна в публичной бета-версии.
Одной из новых возможностей был заявлен механизм vSphere APIs for IO Filtering (VAIO - как ноутбуки от Sony), который позволяет получать прямой доступ к потоку ввода-вывода (I/O Stream) гостевой ОС виртуальной машины. Несмотря на то, что об этой штуке писали достаточно мало, механизм VAIO в будущем будет способствовать созданию множества партнерских продуктов для решения самых разнообразных задач. VAIO основан на механике Storage Policy Based Management (SPBM), которая предназначения для управления хранением виртуальных машин.
Техническая реализация данного механизмв подразумевает использование драйвера VAIO (filter driver), который устанавливается на хосте VMware ESXi как пакет VIB и не требует установки никакого специального ПО в гостевой ОС виртуальной машины. Работает он на уровне VMDK-диска отдельной ВМ и позволяет не только получать данные из потока ввода-вывода, но и изменять его при течении данных в ту или другую сторону.
Это открывает возможности для применения VMware VAIO при решении следующих типов задач:
Encryption – стороннее ПО за счет использования механизма VAIO может на лету шифровать и расшифровывать поток данных от виртуальной машины. Таким образом на хранилище будут помещаться уже шифрованные данные. Гранулярность работы VAIO позволяет обслуживать данные идущие даже не от всей виртуальной машины, а только от одного приложения.
De-duplication - этот механизм уже использует решение VMware Virtual SAN. В реальном времени можно дедуплицировать данные, проходящие через драйвер и в таком виде уже класть на хранилище в целях экономии дискового пространства. Теперь это станет доступно и партнерам VMware.
Tiering - данные различной степени важности, критичности или классифицированные по другим критериям теперь можно класть на хранилища с разными характеристиками производительности и доступности (ярусы). Механизм VAIO тут поможет проанализировать характер данных и определить конечное их место назначения.
Analytics - теперь можно анализировать непосредственно поток данных от конкретной виртуальной машины и на основе этого строить множество различных решений, включая решения по кэшированию (например, такой продукт как CahceBox можно будет напрямую подключить к гипервизору). Затем можно, например, искать в трафике данные определенных приложений, либо, например, использовать механизм write-back кэширования.
На первом этапе запуска технологии VAIO компания VMware решила остановиться на двух путях ее имплементации:
1. Возможности кэширования данных на SSD-накопителях (write-back кэширование для операций записи). Дизайн-документ для API тут делала компания SanDisk, которая первой будет использовать VAIO в своих продуктах. Вот их презентация:
А вот технология write-back кэширования на стороне сервера с использованием механизма VAIO:
2. Возможности высокопроизводительной репликации. Реализация данного аспекта VAIO позволит получать прямой доступ к потоку ввода-вывода и сразу же передавать его на другой хост, не прибегая к дополнительным механизмам, которые сегодня используются для реализации техник репликации. На данный момент заявлено, что такой тип репликации будет поддерживать ПО EMC RecoverPoint, команда которого принимала участие в разработке техники VAIO.
Однако несмотря на все плюсы технологии vSphere APIs for IO Filtering, в ней есть и негативные стороны:
Во-первых, это вопрос надежности. Так как между виртуальной машиной и хранилищем есть дополнительное звено, которое может рухнуть, понижается и совокупная надежность платформы виртуализации.
Во-вторых, это вопрос производительности. Прослушка трафика посредством VAIO неизбежно создает нагрузку на аппаратные ресурсы хоста ESXi.
В-третьих, это вопрос безопасности. Представим, что я написал софт, который прозрачно шифрует и расшифровывает трафик отдельной виртуальной машины на хосте ESXi, после чего внедрил его в инфраструктуру предприятия, где все это произошло незаметно для пользователей и администраторов. Затем я просто убираю это ПО из гипервизора (например, при увольнении), после чего данные на хранилищах превращаются в тыкву, а компания сталкивается с серьезной проблемой.
В целом же, подход VMware в данном вопросе очень радует - она открывает партнерам возможности разработки собственных продуктов для решения задач пользователей, а значит предоставляет и неплохую возможность заработать.
Первые реализации механизма vSphere APIs for IO Filtering мы должны увидеть уже в первой половине 2015 года, когда выйдет обновленная версия платформы VMware vSphere 6.
Многие из вас знают компанию Login VSI, которая выпускает продукт Virtual Session Indexer (VSI), предназначенный для симуляции нагрузки и тестирования VDI-сред. Он уже успел стать стандартом де-факто при тестировании инфраструктуры виртуальных ПК у различных вендоров (например, см. тут). Напомним, что это коммерческое решение, а для бесплатного использования доступен продукт VSI Express.
Теперь компания решила подойти к тестированию VDI-инфраструктуры немного с другой стороны - на прошедшей конференции VMware VMworld 2014 была представлена бета-версия продукта Login VUM.
Это решение позволяет в реальном времени создавать нагрузку в виртуальном ПК для различных приложений (то есть открывать окна, выполнять некоторые операции), будто бы за этой виртуальной машиной работает реальный пользователь. Далее, если время выполнения стандартных операций превышает некоторые пороговые значения (например, приложение запускается слишком долго), Login VUM оповещает системного администратора о возникшей проблеме. Похожий способ используют в Водоканале Санкт-Петербурга - раков, обвешанных датчиками, держат в очищенной воде и измеряют их сердечный ритм, отклонения которого свидетельствуют об изменении качества подаваемой потребителям воды.
То есть, это способ мониторинга реальной производительности виртуальной среды посредством некой эталонной виртуальной машины, симулирующей реальную нагрузку. В веб-консоли можно наблюдать за значениями различных параметров этой машины, полученных в течение дня:
Само собой, Login VUM написан не с нуля, а основан на фреймворке Login VSI (технология измерений VSImax), который уже надежно зарекомендовал себя для задач тестирования инфраструктуры виртуальных ПК.
Пока продукт находится в стадии закрытой беты, но его уже можно будет скачать совсем скоро.
Также Login VSI представила свой графический фреймворк Login VSI: Graphics Framework, который позволяет отдельно тестировать чувствительные к производительности графики нагрузки в виртуальных ПК (такие как AutoCAD, Siemens NX или Photoshop). Фреймворк доступен для пользователей продукта Login VSI Pro.
Пример измерения фреймрейта для Автокада при увеличении числа сессий на хосте ESXi:
Видео о том, как выглядит процедура тестирования интенсивных графических нагрузок:
В результате тестирования данные не попадают в VSImax, так как администратору предлагается самостоятельно решить, какой фреймрейт подходит пользователям VDI-инфраструктуры для конкретного приложения и типа нагрузки.
На данный момент Login VSI: Graphics Framework доступен как публичная бета по этой ссылке.
Компания VMware выпустила интересный документ "Microsoft Exchange Server Performance on VMware Virtual SAN", в котором рассматривается случай тестирования нагрузки виртуальных серверов Microsoft Exchange размещенных в кластере Virtual SAN и работающих на серверах VMware ESXi.
В VMware использовали конфигурацию кластера VSAN из пяти узлов (Dell PowerEdge R720xd с процессорами Intel Xeon Processors E5-2650 и 128 ГБ памяти в каждом), на одном из узлов была машина с контроллером Active Directory, а для генерации нагрузки использовался отдельный клиент:
Детальная конфигурация стенда:
В качестве программной платформы использовался Exchange Server 2010, установленный в ОС Windows Server 2008 R2. На каждом хосте было размещено две виртуальных машины с Exchange - роли Mailbox и HUB.
С помощью Exchange Load Generator была сгенерирована нагрузка пользователей отсылающих и получающих письма. Для теста взяли 12 000, 16 000 и 20 000 пользователей с профилем нагрузки 150 отправляемых писем в день. Каждый почтовый ящик был инициализирован в размере 100 МБ.
При тестах Sendmail на указанном количестве пользователей выведен средний результат выполнения операций (Avg) и результат, уложившийся в 95 процентов опытов (95% latency).
Поскольку принято считать, что Latency до 500 миллисекунд для Exchange считается нормальной при отправке писем - то результаты тестов показывают, что такая конфигурация вполне жизнеспособна на десятках тысяч пользователей.
Больше подробностей можно узнать непосредственно из документа.
Вчера компания VMware выпустила обновление для платформы виртуализации VMware vSphere 5.5 Update 2, которое включает в себя апдейты составляющих компонентов - ESXi 5.5 Update 2 и vCenter Server 5.5 Update 2.
Основные новые возможности обновления:
Поддержка хостов ESXi с объемом памяти до 6 ТБ.
Агентское ПО VMware vShield Endpoint Thin Agent для поддержки взаимодействия с решениями vShield, которое устанавливается в гостевых ОС вместе с VMware Tools, теперь называется VMware Tools Guest Introspection plugin.
vCenter Server 5.5 U2 теперь поддерживает следующие внешние СУБД: Oracle 12c, Microsoft SQL Server 2012 Service Pack 1 и Microsoft SQL Server 2014.
Поддержка vCloud Hybrid Service (vCHS, переименован в vCloud Air) - теперь в vSphere Web Client на стартовой странице появился новый контейнер Hybrid Cloud Service, который содержит установщики vCHS и vCloud Connector.
Появились технические средства программы Customer Experience Improvement Program - теперь данные о конфигурации вашей виртуальной инфраструктуры на еженедельной основе могут передаваться на сторону VMware, чтобы она могла шпионить анализировать их и улучшать продукт.
Множественные исправления ошибок, о которых можно почитать в Release Notes.
При этом у данного релиза есть следующие особенности:
Начиная с vSphere 5.5 Update 2, операционные системы Windows XP и Windows Vista не поддерживаются для vSphere Web Client. Полный список поддерживаемых систем находится в VMware Compatibility Guide.
Так как Linux-платформы больше не поддерживаются механизмом Adobe Flash, то Web Client не поддерживается в ОС Linux. Но не поддерживается - не значит, что это прекратило работать.
VMware vCenter Server Appliance в vSphere 5.5 поддерживает гайдлайны по обеспечению ИБ DISA Security Technical Information Guidelines (STIG), поэтому перед использованием этого решения надо бы почитать VMware Hardened Virtual Appliance Operations Guide для того, чтобы узнать о новых стандартах безопасности и о том, как нужно работать, чтобы security-примочки не мешали.
В VMware vSphere 5.5 U2 больше не поддерживается СУБД IBM DB2 как база данных для vCenter.
Вся информация касательно установки VMware Tools в гостевых ОС теперь представлена в общей документации по VMware vSphere (начиная с версии 5.5).
vSphere Data Protection 5.1 не совместима с vSphere 5.5 по причине изменения рабочих процессов в vSphere Web Client. То есть, вместе с vSphere надо обновлять и VDP.
При обновлении компонентов виртуальной инфраструктуры посмотрите также Interoperability Matrix.
Скачать VMware vSphere 5.5 Update 2 можно по этой ссылке. Документация доступна тут.
Компания VMware на днях выпустила окончательную версию настольной платформы виртуализации для Mac OS VMware Fusion 7. Не знаю, как у вас, а на моем маке Fusion за два года не дала ни одного сбоя. Эти строки тоже пишутся в винде под VMware Fusion 6.
Итак, новые возможности VMware Fusion 7:
1. Обновление Fusion поддерживает новую Mac OS X Yosemite (в том числе в качестве гостевой ВМ). Визуальные улучшения включают в себя новую плоскую иконку, полупрозрачные элементы и поведение перехода в полноэкранный режим в стиле Yosemite.
Появились новые иконки в библиотеке, которые показывают состояние виртуальной машины (запущена или нет) в представлении списком.
2. Новое поколение виртуального программного обеспечения - Hardware Version 11. (VM > Settings > Compatibility).
VMware Fusion Pro поддерживает самую последнюю версию виртуального аппаратного обеспечения (virtual hardware), которое обеспечивает следующие возможности:
Поддержка функций процессоров семейства Haswell, включая поддержку инструкций AVX2 в виртуальной машине.
Новая виртуальная веб-камера, которая упрощает использование маковской вебки iSight в виртуальной машине Windows.
Поддержка HD-аудио формата 5.1 и технологии Bluetooth 4.0.
Обновленный USB-контроллер с поддержкой XHCI 1.0.
Новый подход к виртуальной видеопамяти - теперь она выделяется для каждой виртуальной машины отдельно (VM > Settings > Display). Не рекомендуют выделять гостевой ОС слишком много (будут глюки) и слишком мало видеопамяти (будут тормоза).
Возможность указать интегрированный или дискретный GPU на хосте для использования в виртуальной машине. На последних Mac Book Pro, которые могут иметь оба модуля, это может увеличить время работы от батареи.
Улучшение производительности машин до 60% (для легких нагрузок).
4. Обновленная поддержка конфигураций с несколькими мониторами, один из которых Retina. Также есть возможность определить поведение при переключении между Retina и обычным дисплеем.
5. Возможность настраивать горячие клавиши отдельно для каждой ВМ (VM > Settings > Keyboard & Mouse).
6. Улучшенная поддержка предрелизных версий Microsoft Windows.
7. Новый упрощенный способ установки VMware Tools под Windows 8 с использованием виртуального устройства USB CD virtual device.
8. Поддержка просмотра хостов VMware Workstation, VMware ESXi, VMware vSphere в библиотеке (в меню нужно выбрать File > Connect to Server). А именно:
Удаленная консоль с мышью и клавиатурой
Возможность выбрать CD, DVD, floppy devices или файлы на вашем Mac для подключения к ВМ.
Возможность включения и выключения ВМ, а также выбор виртуальной сети для адаптеров.
Перемещение виртуальных машин с Mac на удаленный компьютер (и наоборот) путем обычного перетаскивания.
Просмотр состояния удаленного сервера с помощью средств Activity Monitor.
9. Возможность удаленного управления виртуальными машинами на платформах VMware Workstation, VMware ESXi и VMware vSphere.
10. Возможность перенаправления аудиопотока гостевой ОС на конкретное аудиоустройство вашего Mac.
11. Улучшенная поддержка новых ОС Linux (в частности, Ubuntu 14.xx, RHEL 7, CentOS 7, Fedora 20 и Debian 8).
Не так давно мы писали о публичной бета-версии VMware vSphere 6, где каждый желающий мог скачать ее, посмотреть на список новых функций, но написать об этом не мог. На конференции VMware VMworld 2014 мораторий, по-сути, был снят - и теперь можно писать и рассказывать о новых возможностях платформы сколь угодно подробно.
Итак, что нового мы увидим в первой половине 2015 года (а именно тогда выйдет VMware vSphere 6):
1. Поддержка технологией Fault Tolerance до четырех виртуальных процессоров машины (4 vCPU).
Теперь технология непрерывной доступности VMware Fault Tolerance будет поддерживать виртуальные машины с 4 vCPU и объемом памяти до 64 ГБ.
Ранее для работы FT использовался механизм "Record-Replay" средствами технологии vLockstep, который воспроизводил инструкции основной машины на резервной. Теперь же используется техника Fast Checkpointing, которая позволяет организовать исполнение потока инструкций одновременно на обеих машинах. Если по какой-либо причине сетевое соединение между машинами замедляется, основная машина тоже начинает работать медленнее.
При этом теперь VMware Fault Tolerance можно будет конфигурировать для включенной виртуальной машины. Однако, по-прежнему, остаются следующие ограничения:
На хост ESXi можно иметь до 4 машин, защищенных технологией FT, при этом всего суммарно может быть защищено до 8 vCPU. Обратите внимание, что эти максимумы применяются суммарно к Primary и Secondary виртуальным машинам, расположенным на этом хосте.
Обязательно потребуется адаптер 10 Gb. Можно будет его разделять между различными типами трафика средствами NetIOC.
Нельзя использовать горячее добавление CPU или памяти для таких машин (Hot Add).
Если несколько vCPU затронуто технологией FT, то для таких машин не поддерживается Storage vMotion.
Кроме того, технику SMP-FT не поддерживают такие вещи, как vCloud Director, vSphere Replication, VSAN/vVols и vFlash.
При этом для таких машин полностью поддерживается VMware vMotion, а также они (как и раньше) защищаются кластером VMware HA - если с одной из машин что-то случается, то на другом хосте перезапускается реплика, которая уже становится Secondary VM.
Помимо этого, надо понимать, что SMP-FT вызовет падение производительности гостевой ОС, по оценкам VMware - это около 10-30% в зависимости от нагрузки.
Приятная новость - многопроцессорная FT будет поддерживать снапшоты виртуальных машин, а значит вы сможете делать их резервные копии средствами Veeam Backup and Replication или любым другим средством, поддерживающим vStorage APIs for Data Protection.
2. Улучшения горячей миграции виртуальных машин на большие расстояния (long distance vMotion).
О long distance vMotion мы уже писали вот тут, а впервые - вообще пять лет назад. И только сейчас обещания станут реальностью.
Теперь работающую виртуальную машину можно перемещать на расстояния, где RTT (Round Trip Time) в канале достигает 100 мс (неофициально поддерживается значение 150 мс). Это в 10 раз больше, чем было раньше.
И это - расстояние до 3000 километров (!). Теперь менеджерам датацентров открываются очень интересные стратегии по таким вариантам использования, как Follow the sun (машины работают там, где работают люди) и Follow the moon (машины работают ночью, когда электричество дешевле).
Кроме того, появились следующие улучшения технологии vMotion.
vMotion между разными серверами vCenter (нужна сеть на скорости 250 Mbps). Это происходит средствами протокола VMware Network File Copy (NFC).
Маршрутизируемый трафик vMotion (наконец-то).
vMotion между виртуальными коммутаторами vSwitch, а также Virtual Distributed Switch (VDS), поддерживаются режимы VSS to VSS, VSS to VDS, VDS to VDS (а вот VDS to VSS - нельзя).
средствами VMware NSX сетевые настройки машин могут быть перемещены в горячем режиме даже, если используется long distance vMotion.
3. Улучшенная производительность и новые возможности vSphere Web Client.
Здесь пока не сильно много деталей: появятся библиотеки контента (версии машин, темплейтов) и функции publish и subscribe для них. Также существенно будет улучшена производительность и уменьшен отклик при различных операциях.
Все это приходит в рамках концепции создания конвергентной инфраструктуры и развития парадигмы Software-Defined-Datacenter.
Здесь используются три основных элемента:
Vendor Provider (VP) – это плагин от производителя системы хранения данных, поддерживающий VVols через VASA API версии 2.0.
Storage Containers (SC) – это контейнеры на дисковом массиве, в которые упаковываются VMDK-диски каждой из машин. Это операбельная единица со стороны и системы хранения, и платформы VMware vSphere.
Protocol Endpoints (PE) – это средства управления томами на базе политик, предоставляемые администраторам. В них уже не будет понятий LUN и точек монтирования. Будет просто VVol, который можно привязывать и отвязывать от серверов ESXi/vCenter.
Все хранилища будут управляться на базе политик (сейчас это реализовано в VSAN):
5. Технология Virtual Datacenters.
Концепция виртуальных датацентров объединяет в себе пул вычислительных кластеров, кластеров хранилищ и политики их покрывающие. То есть это такой большой ресурсный контейнер, в котором есть зачатки интеллекта: он решает в какой из кластеров поместить виртуальную машину и на каком хранилище размещать виртуальные диски, чтобы это соответствовало определенным политикам.
По сути, это еще один уровень абстракции для крупных инфраструктур, в которых можно оперировать вот такими большими объектами из нескольких кластеров серверов и хранилищ.
6. Новые максимумы для хостов ESXi.
Нам обещают следующие параметры:
320+ pCPU
4+ TB Mem
4096+ vCPUs
32+ Nodes/Cluster
62TB+ VMDKs
Также с большой долей вероятности в VMware vSphere 6.0 мы увидим следующие возможности, о которых говорили на VMworld 2014:
Полная поддержка NVIDIA GRID vGPU - больше информации доступно тут.
Технология vSphere APIs for IO Filtering (VAIO) - о ней рассказано здесь.
Технология VMFork - метод по мгновенному клонированию запущенных виртуальных машин.
Больше подробностей о VMware vSphere 6 можно прочитать вот тут.
На проходящей сейчас в Сан-Франциско конференции VMworld 2014 компания VMware представила несколько интересных анонсов, которые (как всегда) открывают много возможностей для ИТ-инфраструктур различного масштаба. Одним из таких анонсов стал выпуск решения VMware EVO:RAIL, предназначенного для построения конвергентной инфраструктры.
На днях компания VMware выпустила долгожданный онлайн-сервис Virtual SAN Sizing Tool, который позволяет оценить необходимые аппаратные мощности, требующиеся для поддержания инфраструктуры хранилищ VSAN на базе локальных дисков серверов VMware ESXi.
В качестве исходных данных утилиты принимается конфигурация типовой виртуальной машины:
а также типовая аппаратная конфигурация хост-сервера ESXi:
Для виртуальных машин вам могут показаться непонятными параметры "Number of failures to tolerate" и "Number of disk stripes per object" - о них мы писали вот в этой статье.
В качестве результата расчетов будет выведена следующая информация:
Число хостов заданной конфигурации, необходимых для поддержания инфраструктуры VSAN.
Размер SSD-диска для дисковой группы HDD на хосте.
Максимумы по числу компонентов в кластере (машины, диски).
Полезная емкость кластера (зависит также от параметра FTT).
Емкость кластера по оперативной памяти.
Кроме того, дается брейкдаун по использованию дисковых емкостей, а также объем оперативной памяти под нужды Virtual SAN на хостах:
При расчетах используются следующие допущения:
Все хосты кластера имеют одинаковый аппаратный профиль, включая число HDD и SSD-дисков, объем памяти и количество ядер CPU.
Предполагается, что у всех виртуальных машин одинаковые требования к хранилищу: как по дисковой емкости и числу дисков, так и по нагрузке на СХД.
Предполагается, что у всех виртуальных машин одинаковая VSAN Policy, то есть параметры FTT и disk stripes per object.
Никаких кнопок для начала расчета нажимать не нужно - данные формируются "на лету". Приступить к работе с VMware Virtual SAN Sizing Tool можно по этой ссылке.
Почти три года назад мы писали про средство VMware I/O Analyzer, предназначенное для генерации нагрузки и анализа статистики ввода-вывода хостов VMware ESXi, доступное на сайте проекта VMware Labs. Не так давно вышло обновление этого средства, которое, как оказалось, живет и развивается.
VMware I/O Analyzer поставляется в виде виртуального модуля (готовой ВМ), предоставляющего администраторам следующие возможности:
Интегрированный фрейворк для тестирования производительности хранилищ средствами генераторов нагрузки.
Готовый к развертыванию виртуальный модуль (управляющая ВМ и "воркеры" - генераторы нагрузки).
Прост в настройке и возможность исполнения тестов на одном или нескольких хостах ESX/ESXi.
Возможность просмотра результатов производительности как на уровне хоста, так и на уровне гостевой ОС.
Возможность экспорта данных для последующего анализа.
Средства "повторения" нагрузки на хранилища путем ее воспроизведения из трейса ввода-вывода.
Возможность загрузки трейсов ввода-вывода для автоматического извлечения необходимых метрик.
Графическая визуализация метрик и результатов анализа производительности.
В обновленном VMware I/O Analyzer 1.6.x появились следующие возможности:
Улучшенный планировщик заданий ввода-вывода.
Сам виртуальный модуль теперь на платформе SLES 64-bit, а сервер на Tomcat 6.
Экспериментальная поддержка статистик клиента NFS.
Возможность использования непостоянной (non-persistent) конфигурации (без сохранения настроек).
Сама ВМ с I/O Analyzer теперь версии 7, что позволяет запускать и использовать ее в ESX/ESXi 4.x.
Улучшения на бэкэнде, позволяющие поддерживать до 240 и более генераторов нагрузки.
На самом деле с 2011 года много что изменилось в этом продукте, поэтому ознакомьтесь с юзер-гайдом, в котором есть история добавления фичей по версиям.
Скачать VMware I/O Analyzer можно по этой ссылке. Очень хорошо, что подобные утилиты не ограничиваются одним релизом, а развиваются и обрастают функционалом.
RSS
